home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 17 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.7 KB
  1. Subject: Re: Colour. 
  2. Date: Mon, 30 May 94 14:26:07 +0100
  3. From: sjg
  4. X-Mts: smtp
  5. Precedence: bulk
  6.  
  7.  
  8. > As I see it, the major issues with colour palette handling by GEM
  9. > programs are:
  10. > 
  11. >     - The standard 16 colours
  12. >         - They're different under MultiTOS (right?)
  13. >         - When should a program desire to change them?
  14.  
  15. Basically I think you've got it right below.
  16.  
  17. >         - When should a user desire to change them?
  18.  
  19. I don't see this as our concern - if a user wishes to change the colours,
  20. let him/her. Presumably (s)he has a good reason to do it...
  21.  
  22. > 
  23. >     - Sharing colours
  24. >         - No point each program allocating its own Purple
  25. >         - When colours must be changed, it would be nice for
  26. >            the actual palette change to be minimized (eg. purple
  27. >            changes to dark purple, not green)
  28.  
  29. The problem here is that GEM (unlike X) has no concept of shared colourmaps.
  30. All colour resources are global. This is a pity, but I can't see Atari doing
  31. anything about it. They could add the functionality to MultiTOS though.
  32. (eg: send a WM_REMAPCOLS on a window change)
  33.  
  34. >     - True Colour emulations
  35. >         - Some programs use a 5x5x5 or 6x6x6 colourspace, and
  36. >            these should all be the same space.
  37.  
  38. Perhaps we need the equivalent of Visuals on a app-by-app basis. So an app
  39. could register its intent to use a 'type' of colourmap. So if we support
  40. 6x6x6 as PSEUDOTRUE, a STANDARD     256 and 16-entry (depending on display depth)
  41. colourmap, and a PRIVATE 256 & 16-entry colourmap, any app could know what
  42. type of colourmap is currently selected, and on receiving WM_TOPPED, could set
  43. its own colourmap if necessary.
  44.  
  45. You'd end up with:
  46.  
  47. main()
  48.     {
  49.     char cmsPresent =0;
  50.  
  51.     app = appl_init();
  52.     if (getCookie("GCMS")) /* Gem Colour Management System */
  53.         {
  54.         cmsPresent = 1;
  55.         cmsRegister(PRIVATE);
  56.         cmsSetPalette(depth, uchar *R, uchar *G, uchar *B);
  57.         cmsChangePalette();
  58.         }
  59.  
  60.     ...
  61.  
  62.     in event loop:
  63.  
  64.     case WM_TOPPED:
  65.         if (cmsPresent && (cmsGetCurrent() != colourMyType() ))
  66.             cmsChangePalette();
  67.         ...
  68.         break;
  69.  
  70.     case WM_UNTOPPED:    /* At last - a use for it!    */
  71.         cmsSetStandardPalette();
  72.         break;
  73.     ...
  74.  
  75.     /* Handle iconify similarly                */
  76.  
  77.  
  78. Of course, the main drawback is that no current apps will support this, but
  79. since there isn't already a standard, I don't see that anything could get
  80. around this.
  81.  
  82. I think the main problem is trying to take a colour allocation 'system' that
  83. was designed for a single-tasking environment and making it work in a multi-
  84. tasking environment. In that vein, I think the way we ought to go about it is
  85. to add functionality when something happens that couldn't have happened in the
  86. old system, ie: when a new app is topped. 
  87.  
  88. You could watch for 'mouse entering window', but to be honest, I fins that a
  89. pain on the X display. If you have a toolbar, and an image, assume that 
  90. they're not joined together, then every time you select a tool the window 
  91. colours go
  92. mad. (I'm thinking of the X application Tgif :-)
  93.  
  94. The DSP decoder from Brainstorm works in the change-on-Topped fashion, and that
  95. works well. I showed it to friends who also use X and "5 out of 5 friends said
  96. that they preferred it" - but cattomeat Today (damn! - getting carried away :-)
  97.  
  98. I'm dubious about whether changing on manipulation is a good idea. I suppose it
  99. is, but it makes implementation more difficult. If a user really needs to see
  100. the desktop files in C:\apps and the colours aren't letting him, then a click 
  101. on
  102. the window should restore all.
  103.             
  104. A program (GEMCMS.PRG) in the auto folder could register the cookie, and
  105. reserve mem for (say) 30 apps. Have a .cpx that llows you to configure this on
  106. the fly, and then you just need binding support (libgem.olb could incorporate
  107. it easily, lattice/pure/any other may have more difficulty - for these a 
  108. separate lib may be necessary.)
  109.  
  110. So what have I missed / how is it inadequate ?
  111.  
  112. Simon.
  113.  
  114.